
United States Patent and Trademark Office 




EPARTMENT OF COMMERCE 
t and Trademark Office 
NER FOR PATENTS 



iigjnia 22313-1450 



APPLICATION NO. 



FILING DATE 



FIRST NAMED INVENTOR 



ATTORNEY DOCKET NO. 



CONFIRMATION NO. 



09/801,602 



24737 



03/08/2001 



Petrus Hubertus Maria America 



NL 000121 



5313 



7590 



03/23/2006 



EXAMINER 



PHILIPS INTELLECTUAL PROPERTY & STANDARDS 
P.O. BOX 3001 

BRLARCLIFF MANOR, NY 10510 



VU, TUAN A 



ART UNIT 



PAPER NUMBER 



2193 



DATE MAILED: 03/23/2006 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Office Action Summary 


Application No. 

09/801 ,602 


Applicant(s) 

AMERICA, PETRUS HUBERTUS 
MARIA 


Examiner 

Tuan A. Vu 


Art Unit 
2193 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 
• Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 

Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)^ Responsive to communication(s) filed on 19 January 2006 . 
2a)S This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Qt/ay/e, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) ^ Claim(s) 1-9,11,13-14 and 16-18 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) IEI Claim(s) 1-9,11.13.14 and 16-18 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10)D The drawing(s) filed on is/are: a)D accepted or £)□ objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
11 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12)D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) O Notice of References Cited (PTO-892) 

2) LJ Notice of DraftspersorVs Patent Drawing Review (PTO-948) 

3) O Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 

Paper No(s)/Mail Date . 



4) O Interview Summary (PTO-413) 

Paper No(s)/Mail Date. . 

5) □ Notice of Informal Patent Application (PTO-152) 

6) □ Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 7-05) 



Office Action Summary 



Part of Paper No./Mail Date 20060310 



Application/Control Number: 09/80 1 ,602 Page 2 

Art Unit: 2193 

DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 1/19/2006. 

As indicated in Applicant's response, claims 1, 3 have been amended. Claims 1-9, 11, 
13-14, and 16-18 are pending in the office action. 

Claim Rejections - 35 USC § 112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

3. Claims 1-9, 11, 13-14, and 16-18 are rejected under 35 U.S.C. 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

Claim 1 recites the limitation "in the requirement object models" in line 25. There is 
insufficient antecedent basis for this limitation in the claims. There is recital of an initial 
requirement model, some additional amended model(s) and a final model; but from the claim as 
a whole, this 'requirement object models' limitation does enable a clear understanding as to 
which of the recited models or combination thereof this is referring to. That is, one skill in the art 
would not be able to construe what constitute a plurality of requirements models in light of the 
incremental steps of amending as recited, particularly in the context of 'expressing the 
differences between the 'members of the family 5 of complex systems when in fact there is no 
explicit correspondence of any 'member' of the so-called 'family' with any of the requirement 
model instances as these are formed in the course of the method steps. This limitation will be 
interpreted as any complex system model. 
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Claims 3 and 9 recite the same limitation and are rejected for not being able to remedy to 
the deficiency of the base claim. 

The dependent claims to claim 1, 3 and 9 are also rejected. 

Claim Rejections - 35 USC §103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 1-2, 4-5, 8-9, 11, 13-14, and 16-18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Regnell et al., "From Requirements to Design with Use Cases", 3 rd Intl 
Workwhop on Requirements Engineering - Proceeding CAISE '97, June 1997 (hereinafter 
Regnell), in view of Don Heim, "Requirements Management with Use Cases" Software 
Technology Conference, May 1999 ( hereinafter Heim). 

As per claim 1, Regnell discloses a method for simultaneously developing a family of 
complex systems including a plurality of complex systems ( market, countries, standards - pg. 2, 
ch. 2: Context - Note: complex systems including more than one plurality of such systems based 
on market, country or standard reads on family of plurality of systems) having a common 
software architecture platform, the method comprising: 

forming a requirements object model (ROM) which explains the abstract concepts in 
terms of structured vocabulary (e.g. Fig. 1, pg. 5 - Note: abstract symbols of Tool for 
representing graphically a use case reads on interaction in terms of abstract concepts from a 
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structured vocabulary; Cll, CI 2 ... C14, Component Model - Fig. 2, pg. 5; MSC, Pseudo code - 
last para, pg. 5); 

developing the use cases based on the set of requirements object model (e.g. Fig. 2, 3, pg. 
5, 6 and related text ) such that the use cases are expressed using the structured vocabulary of the 
requirements object model (e.g. Use Case Model: Textual description of the use cases Ul, U2, U 
-Fig. 1); 

the use cases describing interaction of users with each of the complex systems in terms of 
the structured vocabulary explaining the abstract concepts(e.g. Fig. 3; Use Case Model: textual 
descriptions Ul, U2, £/J-Fig. 1); 

forming functional requirements specification (FRS) which includes use cases (e.g. 
Functionality Specification - Fig. 1, pg. 5 ). 

But Regnell does not explicitly disclose constructing an initial requirement object model 
(ROM), an initial set of use cases, a initial FRS; and forming an amended ROM, forming 
additional use cases based on the amended ROM; changing the FRS simultaneously with the 
additional use cases, repeating formation of additional use cases, amended FRS and ROM until 
desired use cases have been formed and considered; and obtaining a final ROM once all the 
desired use cases have been considered. 

Making iterative adjustment to graphical representation, model representation data (or 
use case scenarios) like those disclosed by Regnell in order to abstracting or implementing the 
functions as required by design/logical model/specifications (or FRS) so to improve the system 
via such mapping and readjustment of said scenarios was a known concept at the time the 
invention was made because, according to known practice at the time the invention was made, it 
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is much preferred to spend resources up front than to ensue rectifying actions and its costly 
consequences when the product is finalized and in use. Accordingly, Regnell discloses how to 
evolve a design from existing stages using evolution and incremental approach via which the 
consolidation of a component specification via a functional distribution model by Regnell using 
further validation and traceability activities as well as multiple incremental projects (see Regnell, 
pg. 6-8; three increments - pg. 9 ch. 5. 1 ; Evolution, Incremental development - pg. 2); and that 
already entails the need for improving as much as possible during the requirements and pre- 
design stage. Because a use case is a symbolic mirror of a set of functional requirement, the 
amending of the requirement object model along with the amendment of use case scenarios from 
Regnell would have been strongly suggested if not implicitly disclosed. The incremental 
improvement to a model and prototype in complex system with of use cases to effect change to a 
requirement model is evidenced in Heim's teachings. Heim, in a method to capture requirements 
for an information system related to a Patient-Record Military Heath System using Use Cases 
analogous to Regnell' s, discloses requirement capture using use cases and incremental changes 
via iteration of scenarios involving creating model and use cases until a suitable prototype can be 
tested (e.g. pg. 8), i.e. a change in a use case leading to change to its description using a specific 
structural vocabulary as implemented by the CASE-tool. In case Regnell does not provide 
successive amending of the ROM simultaneously with developing use cases and further 
repeating the cycle ROM change followed by Use Case changes reflecting the changed ROM 
until a fine-tuned ROM is achieved, then it would have been obvious for one of ordinary skill in 
the art at the time the invention was made to implement the ROM by Regnell in light of the 
incremental approach by Heim, i.e. generating an initial set of FR or use cases, then make 
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incremental change to the ROM, use cases and FR, with upgrading ROM, Use cases, and FR in 
response to each increment until a final ROM is achieved. Because each use case represents an 
aspect among more complex business patterns or required functionalities of complex families of 
business logic and making incremental improvement to the requirement model in conjunction 
with new use cases adjustments (changes being imparted to the corresponding description using 
a specific structural vocabulary) the final, one skill in the art would be motivated to do the above 
improvement to Regnell's incremental approach using Heim's teaching because this would 
increase the chance of weeding out imperfection at the requirements stage in the functional 
model approach by Regnell and according to well-known concept of software development, 
alleviate costly drawbacks during later stages of the software lifecycle just as in the traceability 
costs analysis emphasized by Heim or suggested by Regnell. 

Regnell does not expressly disclose expressing the differences between members of the 
family of complex systems via a plurality of requirement models but discloses differential 
between members of a same family of project (Fig. 5, pg. 9) and tailoring of resources in order to 
address needed improvement per each versioned member thereof (Regnell: team - ch. 5.1). 
Regnell also discloses a specific set of parameters that can be attributed to a family of target 
systems (see market, countries, standards - pg. 2, ch. 2) and expressed these aspects for each 
such family, or domain of knowledge or application but via projects developed and integrated. 
Based from Regnell's endeavor to address improvement based on what is detected early as 
different between members of a family or an aspect of domain of knowledge {early definition ... 
between components, allowing parallelization - pg. 12, ch. 6), it would be obvious for one skill 
in the art at the time the invention was made to implement Regnell's domain modeling so that 
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the establishing of model representation for each aspect of a family of complex systems also 
includes the differences between the aspects or members of each family. One skill in the art 
would be motivated to do this because having established early knowledge on differences to 
distinguish aspects, members or versioned instances of a family of complex systems would 
enable specific resources to be allotted just to develop and identify the similitude, differences, 
weakness and strengths of what is to be implemented for such distinct member or aspect or 
version thereof; hence increase efficiency ( see methodology team, parallelization, reduction of 
...use case - Regnell ch. 5.1, 5.2 ; early definition ... between components, allowing 
parallelization - pg. 12, ch. 6), i.e. enable repartition of or reducing redundant recreation of 
resource/responsibilities and specialization of one aspect (family member) based on the 
knowledge on the differential or variants of the members per family, or the aspects per domain of 
knowledge (e.g. test cases... different flow variants - pg. 11, bottom). 

As per claim 2, Regnell discloses complex business system and a plurality of developed 
subprojects with coordination of teams aimed as perfecting a model design or models (- pg. 9 ch. 
5.1) and management of the hierarchy of components related to use cases ( e.g. pg. 6-7); hence 
has suggested establishment/organization into teams responsible for requirements and design; 
modeling/validating and for constructing scenarios mapping each assigned section of the 
complex system subcomponents or chapters of a master FRS document. 

It is a well-known concept that managing a large software project using developing teams 
with overlapping responsibilities ( members of team being used in other teams), from 
requirement analysis, authoring, to design evaluation, implementation, test scenarios and 
verification, change reviews and traceability analysis, at the time the invention was made. 
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Collaborations between use cases being specified by different authors are known in tools like 
Rational Rose or the likes, thus suggesting overlapping and integrating of separately authored 
Use cases as suggested by Regnell ( see development team -pg. 9 ch. 5.1, work parallelization - 
ch. 5.2, pg. 10) or Heim ( see Heim: pg. 8-14). Hence, in case Regnell does not provide 
overlapping teams for authoring requirement specification and modeling of such requirements 
and for handling specific ones of the chapters, it would have been obvious for one of ordinary 
skill in the art at the time the invention was made to provide teams for modeling and for 
authoring requirements so that members of modeling ( e.g. object model control team) teams 
cooperate with members of the requirement authoring team as taught by common practice as 
mentioned above. The motivation would be to enable repartition of resource/responsibilities and 
specialization of domain knowledge as well as knowledge sharing; hence facilitate supervision 
and interdependency control and/or concurrent development conflict resolution; all of these 
concepts being integrated in to the common overlapping team concept as mentioned above. 

As per claim 4, Regnell discloses initial model ( Fig. 1, 2, 3) as specified in claim 1 but 
does not explicitly disclose constructing one from a team, performing the FRS authoring of use 
cases based upon that initial model and performing fine tuning of the use case and the object 
model. 

But it is well evident that when the team, a limitation being obvious by virtue claims 1-2, 
tackles an aspect of the complex requirement system, the steps of 

constructing an initial requirement object model ( Note: creating a initial object model 
and populating changes herein is inherent to every software engineering and modeling), 
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authoring a use case therefor are disclosed as being implicit from the teachings recited in 
claim 1 ( see Regnell: Fig. 1, pg. 5 ; Fig. 2, 3, pg. 5, 6 - Note: It is also noted that the use of Case 
Tool with Use Case for requirement analysis like Rational Rose was a known concept; and 
official notice is taken that authoring in a requirement building process in such tool implicitly 
discloses authoring and creating of model graphical representation; and in light of such Regnell 
has disclosed authoring and building of initial model ); and 

fine tuning of the use cases and refining the model would all have been obvious by virtue 
of claim 1 . 

As per claim 5, Regnell does not explicitly that authoring of use cases is carried out in 
parallel by respective requirement authoring teams. The concept of parallel developing of 
software and concurrent authoring of model specification by more than one developers in 
frameworks such as Regnell's using UML or Rationale Rose ( Note: it is not perceivable to have 
a computer tool and many teams to support a complex system development as in Regnell's when 
every stage has to be done in a non-parallel or non-concurrent fashion) was a known concept in 
the art of using Unified Modeling Language or CASE Tools which has been designed for such 
concurrent use of users operating from separate and heterogeneous development environments. 
Hence, Regnell in combination with Heim as set forth in claim 1 , has disclosed concurrent 
authoring Use Case in parallel of models by development team members. 

As per claims 8 and 9, in conjunction with the rational of claim 3 for getting a model per 
member of a family, one model for a complex system among family of models. Official notice is 
taken that subclass being derived from more general classes, multiplicities of relationships exists 
between classes in an model entity; and that model components be hierarchized by properties or 
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attributes according to industrial nature a problem, a domain, a business logic or a system 
behavior, in 00 modeling framework or Case Tools like that of Rational Rose was a well-known 
concept at the time the invention was made. Hence, in view of the teachings by Regnell from 
claim 1 and the rationale in claim 3, the limitation of expressing the differences between 
members of a family in the requirements model would have been obvious if not implicitly 
disclosed. 

As per claim 11, Official notice is taken that in a software development, the analyzing of 
a requirement model or models to identify shortcomings and effecting corrective actions to 
improve such shortcomings are well-known concepts at the time the invention was made. The 
limitation of claim 1 1 would be implicitly disclosed in Regnell' s ( in combination with Heim's) 
complex software systems development in light of the validation and traceability tracing 
teachings as mentioned in claim 1 . 

As per claim 13, although there is no explicit disclosing from Regnell or Heim as to 
considering the FRS to be complete when all the use cases are expressed in the structure 
vocabulary of the final object model, this limitation is implicitly taught in Regnell or Heim's 
requirement fulfilling process ( as per claim 1 1); because if one shortcomings is left unresolved 
in the scheme of requirement validation or verification, the product might not be viable or the 
purpose of the Requirement engineering process as intended by Regnell would be defeated. 

As per claim 14, the limitation as to develop additional use cases simultaneously with 
requirement object models or ROMs has been addressed in claim 1; the limitation that the 
ROMs is thereby formed would also be disclosed based thereupon. 



Application/Control Number: 09/80 1 ,602 Page 1 1 

Art Unit: 2193 

As per claim 16, see Regnell (Use Case Model: Textual description of the use cases Ul, 
U2, C/5-Fig. 1) 

As per claim 17, the claim include the subject matter of claim 1 regarding amendment to 
the use cases and simultaneous adjustment to the requirement models; hence is rejected with the 
rationale as set forth in claim 1 . 

As per claim 18 ( refer to Regnell: Textual description of the use cases Ul, U2, U3 - 

Fig. 1). 

6. Claim 3 is rejected under 35 U.S.C. 103(a) as being unpatentable over Regnell et al., 
"From Requirements to Design with Use Cases", 3 Intl Workwhop on Requirements 
Engineering - Proceeding CAISE '97, June 1997 (hereinafter Regnell), in view of Don Heim, 
"Requirements Management with Use Cases" Software Technology Conference, May 1999 ; 
further in view of Rumbaugh, "UML The View from the Front" 9 March 1 999, Rational 
Software Corporation ( hereinafter Rumbaugh) 

As per claim 3, Regnell does not expressly disclose expressing the differences in terms 
of specialization using subclass of generalized class; multiplicity between classes; and attribution 
with members expressed in values of attributes. The Use case teaching by Regnell includes the 
class/subclass and multiplicity relationship as well as class creation per Use case being expressed 
in attribute value (see Fig 1-4) because the UML case tool was well-known for creating Object- 
Oriented components with interface and association relationship, and methods or internal 
attribution being represented by value instances as these classes are created in a Use case 
scenario as shown via Regnell's Use case, as well as in Rumbaugh UML development ( see pg. 
6-12, 15, 22 or even Quatrani, Visual Modeling with Rational Rose and UML, 1998 - as earlier 
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submitted) for defining interfacing relationship of components at the time the invention was 
made. Based on the rationale as to making the Use case requirement analysis per aspect of a 
domain knowledge or a member of a family of projects as set forth above in claim 1, the use of 
Regnell so that the Use Case creation of member of a family of project to further have 
specialization, multiplicity, or attribution would also have been obvious for the same rationale as 
set forth above, and because of the fact that Use case analysis would always include 
specialization class, multiplicity association and attribution as exemplified by Rumbaugh which 
is a more detailed representation of what is implied via UML-driven Regnell's tool. 
7. Claims 6 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Regnell et 
al. ? "From Requirements to Design with Use Cases", 3 Intl Workshop on Requirements 
Engineering - Proceeding CAISE '97, June 1997; and Heim, "Requirements Management with 
Use Cases" Software Technology Conference, May 1999; as applied in claim 1, and further in 
view of Langlotz, USPN: 6,366,683 (hereinafter Langlotz). 

As per claim 6, Regnell discloses a complex system while Heim discloses that complex 
systems are medical or hospital related application system (pg. 3-4). In a system using modeling 
language similar to the Case Tool to specify an instance of medical application similar to the 
suggestion by Heim, Langlotz discloses the medical system is radiology-related and imaging 
system ( Fig. 1-2). Since medical imaging is but one of many medical diagnostic or hospital 
applications, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to implement one of the business or medical system frameworks as 
suggested by Heim so that a medical imaging or any medical diagnostic application using 
modeling as taught by Langlotz be one of such frameworks, because of the relationships among 
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information data as depicted by Langlotz's medical radiology imaging system would be more 
enhanced for better analysis and reusability when modeling is used. 

As per claim 7, this claim recites the medical imaging limitation of claim 6 in 
conjunction with inter-cooperating teams performing chapters or subsets of the complex FRS as 
addressed in claims 3-5; hence would have been obvious for the same reasons as used in claims 
6, and 3-5 respectively. 

Response to Arguments 
8. Applicant's arguments filed 1/19/2006 have been fully considered but they are either 
moot or not persuasive. Following are Examiners' remarks. 

(A) Applicant has submitted that Regnell fails to disclose "a method for simultaneously 
developing a family of complex systems . . . comprising a step of expressing differences ... of 
claim 1" (Appl. Rmrks, pg. 7, bottom, pg. 8, top). The claim sets out an environment to develop 
family of complex systems, and the method thereof comprises the steps of constructing, forming, 
forming . . . repeating, obtaining and expressing as recited. Each of these steps has been mapped 
with appropriate teachings by Regnell to meet in light of broad reasonable interpretation. 
Applicants fail to show or point out specifically where these mappings would be faulty and why 
so. From the claim, there is no clear association of any member of a family of complex systems 
with any requirement model as such model has been perceived as being repeatedly created 
during the steps, i.e. the 'member' is not defined as to enabling one to reasonably understand it to 
be a system, a model or anything else; and broad interpretation has it that such a member would 
be one complex systems. The rejection of 1 12, 2 para has it established that the 'requirements 
object models' limitation -in plurality- does not enable how this association of a complex 
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system ( or a member) can be expressed in terms of differences between other complex systems 
with respect to those requirement models. The context of many (a plurality of) requirements of 
models (initial model, additional model, final model) is not clear as to which models the complex 
system (if any) is associated with; such that this 'requirement object models 5 also lacks 
antecedent basis. The rejection has addressed this expressing-of- differences limitation in light 
of the lack of definiteness in the claim; and the rejection has set forth why this difference 
expressing limitation would have been obvious. Further, the steps in the body of the claim have 
been addressed as they are set forth in the rejection. Although the claim outset mentions about a 
family, the body of the claim does not establish that the family or any member thereof is 
associated with any model (Note: interaction of use case users with a complex system does not 
necessary mean that a member of a family corresponds to a particular model); nor is there any 
teaching on what being a family really amounts to. Nor does the claim convey that such member 
or members are being expressed simultaneously via any specific model, nor does it refer once to 
one family member throughout the steps of additionally creating requirement model instances in 
the body of the claim after the preamble. Applicants' argument amounts to mere allegation when 
the claim is marred with indefiniteness or lack of consistency. Applicant's arguments fail to 
comply with 37 CFR 1 . 1 1 1 (b) because they amount to a general allegation that the claims define 
a patentable invention without specifically pointing out how the language of the claims 
patentably distinguishes them from the references. 

(B ) Applicants have submitted that Heim does not disclose 'expressing differences in each 
family of a complex system' as clearly recited in claim 1 ( Appl. Rmrks, pg. 8, middle). In 
response, it is noted that Heim is not used to address a limitation that have been deemed obvious 
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by using teachings by one skill in the art at the time of the invention and by Regnell, as set forth 
in the rejection. In response to applicant's arguments against the references individually, one 
cannot show nonobviousness by attacking references individually where the rejections are based 
on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In 
re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 

(C ) Applicants mention about different fields of application in the Office action's combining 
Regnell and Heim (Appl. Rmrks, pg. 9, middle). A Radio system and a health care system both 
use applications founded on complex software systems and both software development approach 
by Regnell and Heim, respective to those systems, use tools like Use case and UML. The 
endeavor to provide team, asset, resources management in light of the Use case analysis and 
incremental improvement to the models is being the main line of approach for the USC 103 (a) 
type of rejection to set forth why the methodologies under this endeavor can be combined or 
deemed complementary to each other in regard to a same utility or purpose. And the desirability 
and motivation to reach such purpose has been put forth in the Office Action. The health care or 
radio fields, considered otherwise a industrial field or intended use, is not considered to be that 
endeavor which is the basis of the rationale of 103(a) - an endeavor wherein software 
development resources can be optimized or minimized via educated attempts to 
improve/increment or to learn from previous builds. In response to applicant's argument that 
Heim in regard to Regnell is nonanalogous art, it has been held that a prior art reference must 
either be in the field of applicant's endeavor or, if not, then be reasonably pertinent to the 
particular problem with which the applicant was concerned, in order to be relied upon as a basis 
for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. 
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Cir. 1992). In this case, the common endeavor is to take advantage of the Use Case tool to set up 
criteria for testing or improvement in order to allocate resources for future or subsequent 
improvement of the complex systems to envisage. The above argument by Applicants is hence 
not persuasive. 

For the above reasons, the claims stand rejected as set forth in the Office Action. 

Conclusion 

9. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 
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The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 



Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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